AWS FargateにおけるAmazon ECS クラスターの効果的な分け方を様々な観点で考えてみた

はじめに

AWS Fargateを使用している際に、ECSクラスターをECSサービスごとやECSタスクごとにどのように分けるかに迷うことがありました。

そこで、個人的に複数の観点からクラスターの効果的な分け方を考えてみました。

なお、この記事ではECS on EC2ではなく、ECS on Fargateのみに焦点を当てています。

ECSについて

ECSの構成について簡単に説明しますと以下の3つに分かれます

• クラスター
  • タスクとサービスを実行する基盤です
• サービス
  • ECSクラスター内で、タスクを実行し管理します
• タスク
  • タスク定義に基づいてコンテナを起動します

今回は、タスクとサービスを実行する基盤であるクラスターをどのような単位で分けるべきかを考えてみました。

一般的

一般的には、システムや環境ごとにクラスターを作成すると良いでしょう。

理由としては、２点あります。

1. リソース作成の簡易化

クラスターを作成する際には、コンソール上のネットワーキングという項目でVPCとサブネットを指定して作成します。

これにより、コンソール上でサービスやタスクを作成する際、下記のように指定したVPCが自動的に選択され、作成が容易になります。

クラスター作成時

ECSサービス作成時

システムや環境別にVPCが分けられていることが多いため、システムや環境ごとにクラスターを分けると、サービスやタスクの作成がしやすくなります。

2 リソースの役割の理解

AWSリソースの命名規則は、「システム名」「環境名」を含めていることが多いです。

そのため、命名規則に合わせて、クラスターの名前も例えば{システム名}-{環境名}-clusterとすることで、各クラスター内のリソースの役割が分かりやすくなります。

以上の２点の理由から、一般的には、システムや環境ごとにクラスターを作成すると良いと考えます

セキュリティの観点

セキュリティの観点ではクラスターを分けることで、特定のユーザーに対して詳細な権限制御が可能になります。

外部の開発ベンダーの方が特定のクラスターのみを利用する場合などに利用されます。

ECSのAPIであるCreateService、UpdateService、DeleteService、RunTask、StartTask APIなどは、AWS IAMのポリシー内のConditionキーを使用して操作可能なクラスターを指定できます。

Conditionキーを活用することで、「特定のユーザーは、Bシステムのクラスターでサービスやタスクを作成・更新できるが、Aシステムのクラスターではできない」といった詳細な権限制御を行うことができます。

サービスのクォータ (制限) の観点

次に、サービスクォータの観点です。

サービスクォータとは、あらかじめ設定されたデフォルトの上限値のことを指します。

ECSのサービスクォータは、下記のドキュメントにまとめられておりますが、その中でもクラスターを分ける観点になりえる項目を表形式でピックアップします

項目	各リージョンのデフォルト	調整
クラスターに関連付けるキャパシティプロバイダー数	20	不可
クラスター数	10,000	可能
クラスターあたりのコンテナインスタンスの数	5,000	不可
クラスターあたりのサービスの数	5,000	可能

これらのサービスクォータが問題になる場合は、クラスターを分けることでクォータの制限を回避できる場合があります。

コストの観点

コストの観点では、２点ございます。

Container Insights

ECSクラスターは、Container Insightsというモニタリング機能を有効にすることができます。

この機能により、クラスター、サービス、タスクのパフォーマンスメトリクスを確認できますが、有効化するとCloudWatchのカスタムメトリクスが自動的に作成されます。

Container Insightsの詳細は下記記事をご参照ください

CloudWatchのカスタムメトリクスの料金は、東京リージョンの場合、1メトリクスにつき0.30 USD/月かかります。

そのため、モニタリング機能が不要なタスクと必要なタスクをクラスター単位で分けることで、不要なコストを削減できます。

タスク停止理由のログ保存

通常、AWS FargateのECSタスクが停止した場合、タスクの停止理由の確認は、コンソール上で確認できますが、1時間を過ぎると削除されます。

過去にさかのぼって確認したい場合、CloudWatch Logsに保存する必要があります。

ログの保存方法は、下記の記事をご参照ください

上記の方法ですと、基本的にクラスター単位でCloudWatch Logsにタスク停止のログが出力されます。（厳密には、タスク定義のリビジョンごとに絞ることもできますが、リビジョンが変わるとログが保存されなくなるため、現実的ではありません。）

クラスター内では、タスク停止のログが必要のないタスクも保存されてしまうため、CloudWatch Logsの保管料金や分析時にノイズになる可能性があります。

これを防ぐためにも、タスク停止のログが必要なタスクのみをクラスター単位で分けるとよいでしょう。

最後に

今回は、ECS on Fargateを利用する際のクラスターの分け方について考えてみました。

適切なクラスターの設計は、コストやセキュリティを含めた効率的な運用に重要です。

他にも色々な考え方でクラスターを分けることがあると思いますが、一例として参考にして頂ければ幸いです。

参考